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(57) Abstract: An online machine data collection 
and archiving process (15) generates a machine data 
profile (18) of a customer computer (5) accessing a 
transaction form of a merchant web site (3) and hnks the 
machine data profile (18) and a transaction record (6) 
with customer identifying information using a unique 
transaction identification string.: The procfess preferably 
captures parameters typically communicated as part of 
web accesses, such as an IP address, an HTTP header, 
and cookie information. The process additionally causes 
the customer computer (5) to process self-identification 
routines by processing coding within the merchant 
transaction form, the self-identification routines 
yielding further profile parameters. The process further 
includes a routine for bypassing an intervening proxy 
to the merchant web site (3) to reveal the true IP address 
of the customer computer (5), 
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1 ONLINE MACHINE DATA CX)LLECnON AND ARCHIVING PROCESS 

2 

^ Ciross-Reference to Provigional Application 

4 This application claims benefits firom provisionat application. Serial No. 

5 60/209,936 ffled June 7, 2000 and entitled METHOD FOR <X)IXECnNGMACHI^ 

6 DATAFROMOTSTOMERSONAGOMPIJTERNETWORK. 
7 

8 Background of the Invention 

9 The present invention relates to identity detection techmques and, more 

1 0 particulariy, to a process for collecting and utiliang machme-identi^ng data ojf computers 

H and other online appliances used in online interactions and transactions and associating the 

1 2 collected machme data with such onfine interactions. . 

13 The internet, or global computer network, represents a new medium for marketing 

1 4 similar to the way mail ordering and telq>hone ordering did m thepast A downside of 

1 5 internet marketing is that it also presaits new opportunities for unscrupulous persons to 

16 take advantage ofthe mechanisms ofintemet transactions by fraudulent and deceptive 

17 practices. I^diants and financial mstitutions bear the iiutikl costs of fraud. Howevo; 

1 8 consumers ultimately pay the costs in tiie form of prices and credit rates which must take 

19 into account losses firom fraud. Internet purchases typically involve tiie use of web page 
2 0 forms wWch are fiUed in by tiie customer wifli identity, address, purchase, shipping, and 

1 



wo 01/97134 PCT/USOl/18076 



1 payment infonnation and submitted to the online merchant for processing. Ihtemet 

2 purchases are most often paid for by way of credit cards. While a merchant's software 

3 may be able to verify the existence and status of a credit card account number and an 

4 authorization for a specific amount, the merchant is often not able to match a credit card 

5 number with a spedfic purchaser or shipping address. Thus, absent any overt indication 

6 otherwise, a merdiant generally assumes that aityone using a credit card is authorized to 

7 do so and that a customer is who he identifies himself to be. 

8 An important step in combating fraud is accurate identification of the computers 

9 through ^ch customers make transactions and associating sudi identities with 

1 0 transactions which arouse suspicions or which ultimately turn out to be fraudulent. Basic 

11 machine identity is essential to the manner in vMch the internet operates. We speakln 

1 Z terras of "going" to a web site. In reality, "going" to a web site involves sending a request 

13 for a web page file in a directory or folder on a computer located at a specific internet 

14 protocol, or IP, address. In order for the web page file to be returned to the requesting 

1 5 computer for processing into a displayed "web page", tiie request must include return 

1 6 "directions" in the form of the basic idaitity of the requesting computer, including its IP 

17 address. Some web sites are implemented witii software which enables responses to web 

1 8 page requests to be taUored to specifics of the requesting niachme's configuration, specific 

1 9 wdj browser, and the like. For this reason, current versions of browsers usually 

2 0 communicate configuration infi)rmation in addition to a return IP address and return path. 



2 
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1 The IP address of a page requesting computer can give an indication of the specific 

2 country where the computer is located. Further, identification of a page-requesting 

3 computer can also recognize a returning user using the same computer as during a 

4 previous access. For esounple, placing an HTTP Owertext transfer protocoO "cookie" on 

5 a page-requesting computer can make it possible to identify the computer on a later 

6 access. 

7 Because direct interaction vdth a customer's computer is essential in detecting 

8 firaud, it has been assumed that any viable firaud detection software must be integrated with 

9 a merchant's software. As a result, most e^d8t^ng fraud detection solutions require 

1 0 merchants to either abandon or extensively modify their existing web-based transaction 

1 1 processing software. An additional problem witii focusing fraud detection at single 

12 merchants is tiiat perpeti^ators of fi^d often hit many merchants in an attempt to avoid or 

13 delay detection. Thus, an ideal system for fraud detection in online marketing would onfy ^ 

14 minimaUy affect the merchant's existing software and would route fraud detection eflEbrts 

1 5 tiirough a central, tiurd-party entity serving a large multitude of merchants. 
16 

^'^ Summary of the Invgntinn 

18 The present invention provides a process for collecting data associated with a 

19 customer's computer during access ofa merchant, financial, other host web site, and 

2 p associating a transaction identification number with tiie data and with a transaction fi)im of 

21 the merchant. Generally, the present invention captures machine identifying data from a 
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1 compute- or other digital appliance accessing a host web site, sends the captured data to a 

2 machine data archive along with a unique transaction identification string for storage in the 

3 arcWve and writes the same transaction identification string into a transaction form 

4 through which transactions with the host web site are conducted. The machine data is, 

5 thus, assodated with the customer identification data within the transaction foim by way 

6 of the transaction identification string and can be used on-the-fly or at a later time for a 

7 variety ofpuiposes including, but not limited to, fiwid detection. Although the teim 

8 "arduve" is used, the machine data collected need not be stored permanently 

9 The machine data collection process of the present invention is intended to be 

1 0 employed in a variety of applications including, but not limited to: online purchases and 

1 1 orders; online banking, biU payment, and fimds transfers; online r^strations, such as fot 

12 m^^xber^s, product warranties, applications for credit, renewal of substaiptions and 

13 licenses; online technical support; and the Hke. The term "transaction" is used in the 

1 4 present invention to describe an uiteraction effected between a digital appfiance and a host 

1 5 system. However, the term "transaction" is not intended to be restricted to only 

1 6 commercial interactions involving purchases. The term "titmsaction" is intended to apply 

17 to an interaction of a remote digital appliance witii a host system uang a relative^ 

18 anonymous type of access process over a digital medhmiini which some fi)nn of self- 

1 9 identification of tiie accessing appliance is inherent in tiie access process and in which the 

20 true identity of flie accessing party, tiie true source address of tiie appliance on tiie 

4 
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1 medium, and/or the true machine characteristics of the accessing appHance is/are essential 

2 or desirable to the interaction. 

3 The host entity which operates the host system accessed is intended to encompass 

4 a commerdal, financial, educational, governmental, assodational, or other ^e of en%. 

5 The term "merchant" will be used herein to refer to such a host entity without int«it to 

6 limit the present invention to commercial transactions. The medium of access is intended 

7 to be interpreted as including a global computer network such as the internet or world 

8 wide web, as weU as other types of networks which may be less than global but which are 

9 publicly and/or anonymously accessible. The term "internet" will be used herein to refer 

10 to the medium through which accesses to the host entity are made. The terms "customer 

11 computer" or "machine" are used herem to refer to a device for eflfecting remote access to 

12 a host system over a digital medhmi and are meant to encompass not only conventional 

1 3 types of personal con^uters, but also additional types of "digital appHances" with online 

1 4 access capabilities, such as: cell phones, personal digital assistant devices, electronic game 

1 5 systems, television sets with online access capabilities, wd) appliances for vdiicles, and 

16 any other type of device with online access capabiliUes whether connected to a wired 

1 7 communications network directly or by a radiant technology. 

1 8 The machme data collection process of the present invention contemplates a two 

1 9 party process embodiment in which a "merchant" processes and/or stores machine data 
2 0 profiles of customer computers in-house, as weU as a three party process embodiment in 
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1 which machine data profiles of customer computers are processed and/or stored for the 

2 merchant by a third-party machine data collection and ardiive service. 

3 In a two party ^bodiment of the data collection process of the present invention, 

4 the customer machine data is captured by a merchant or host system which also generates 

5 a unique transaction identification (ID) string and assigns or associates the transaction ID 

6 with a machine data profile of the customer machine data profile. In the two par^ 

7 process, the merchant system captures customer computer data which is inherently passed 

8 fi-om the customer computer to the merchant's web site, such as an IP address of the 

9 customer computer and an HTTP header. Additionally, according to the present 

1 0 invention, the merchant web page code may have routmes or calls for external routines 

1 1 which, when processed by the customs computer, cause the customer computer to 

12 fiirther identify itself by collecting and returning certain machine and software 

13 configuration characteristics, which can be used to identify the particular customer 

14 computer. The two party process may include the generation and setting of anHTTP 

15 cookie in the customer browser for recognition upon a later access with the merchant web 

16 site. 

17 Although tiie two-party embodiment of the machine data collection process of the 

1 8 • present invention has utility for some applications, the three party embodiment is preferred 

19 for applications in \^ch analysis of a maximum number of customs computer profiles is 
2 0 desirable, such as certain types of marketing processes and fi*aud detection and control 

2 1 processes. In a three embodiment of the present invention, the customer machme data of 
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computers accessing the second party or merchant web site is communicated to and stored 
within a third party system, referred to h^ein as a machme data archive sendee. In the 
three party process, the transaction ID could be generated by the merchant system, but is 
prefmbly generated by the archive service. The use of the term "archive" is not meant to 
indicate that the customer machine data profiles are stored pomanentty witMn the third 
party system. Permanent storage of such profiles may not be practical, as fer as yielding 
benefidal resufts to the purposes for whidi the profiles are collected. Thus, the term 
"ardiive" is meant to indicate a central storage fecility, such as a database, with a selected 
retention period, with purging of most profiles after a certain length of time. 

Li the three party process a routine or line of code is added into the hypertext 
markup language (HTML) code which defines the merchant's w* page, particulariy an 
order or transaction form page. The added routine issues a request for a machine data 
collection (MDC) script to the third-party web site when the form page code Is processed 
by the customa:' s browser. When the saipt request is received by the machine data 
ardiiving sw^ice (MDAS), the ardiive service generates a unique transaction 
identification (TA/ID) and checks for its own cookie. If no MDAS cookie is present, the 
archive service sends a cookie to the requesting computer along with a machine data 
coUection (MDC) script having the transaction ID embedd^ therein. The MDC script is 
executed by the customer's browsw, duising coUection of cratam data from the 
customer's computer which is sent back to the archive service along with the transaction 
ID and stored in a machine data profile in the machine data archive. The transaction ID is 
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1 written into the transaction form, and when the transaction form is submitted to the 

2 merchant web site, the transaction ID string becomes a part of the transaction data record, 

3 along with customer identification, location, and financial information. 

4 The machine data initially collected and stored m each profile preferably includes 

5 the transaction ID, the apparent IP address of the customer's computer, a conventional 

6 HTTP header which identifies the customer's browser versions and certain configuration 

7 aspects of the browser, and the archive service's cookie. The combination of such 

8 information, minus the transaction ID, will be relatively rare but may not be unique. 

9 Additionally, customers intent on conducting fiaudulent transactions often hide their IP 

1 0 address behind HTTP proxies. In order to fiirflier narrow the machine profile, in a 

1 1 preferred embodiment of the present invention, the MDC script performs additional 

12 machine profiling operations: generation ofa machine **fingerprint" and a proxy 
1 3' "piercing^' operation 

14 In the fingerprint generation operation, the MDC script assembles an attribute 

1 5 string formed by various attributes or configuration settings of the browser which can be 

1 6 quOTed by tiie script. The MDC script tiien performs a conversion process on the 

1 7 attribute string to generate a fingerprint string having content vMch is a fiinction of the 

1 8 original content of the attribute string. The conversion process is preferably a "hashing** 

19 fiinction which is, in efiPect, an irreversible encryption algorithm The generation of a 

2 0 conventional checksum is one example of a type of hashing fiinction. For example, if the 

2 1 attribute string is formed by alphanumeric characters, the conversion process is performed 

8 
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on the string of codes representing the characters. The particular conversion process or 
bashing fiinction used may be one of mai^ ^s of conventional conversion algoritiuns oi 
hashing fiinctions, vAudi are typically used for data integrity tests. The resulting string 
from the MDC conversion process is a so-called fingerprint, which is returned to the 
archive service along with the transaction ID for storage in the machine profile. A time 
value, queried fi-om the customer compute time-of-day clocl^ is returned with the 
fingerprint string and stored in coiy'unction therewith. 

An HTTP proxy is one of several types of proxies tiirough which a browser may 
be setup to operate. S^g up an HTTP proxy causes HTTP requests to be relayed by a 
primary gateway, through whidi the computer actually uiterfeces to the internet, to a 
remote secondary gateway, or projqr, with an IP address different Smm the primiaiy 
gateway IP address. Sudi redirection hides the true IP address of a computer. The proxy 
piercing operation of the MDC script queries tiie customer compute for any LAN (local 
area network) address vrfiidi may be assigned to the conq)uta- and reads flie system time 
of day clock. Then attempts are made to send tiie LAN address, if any, tiie time value, 
and the transaction ID to the archive savice uang a protocol which will not be redirected 
through the HTTP pro^gr, for example a lower level protocol sudi as TCP/IP-or UDP 
protocols. If the attempt is successful, the message contaiifing the time value, the 
transaction ID, and LAN address arrive at tiie archive service web site with tiie true return 
IP address of tiie customer computer, whetiier an HTTP proxy intervenes or not The 
LAN address and IP address so derived are stored in tiie machine profile. It should be 
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1 noted that the use of an HTTP proxy is not, of itself, an indication of fraud. However, the 

2 acquisition of an additional JP address is one more parameter with which to identify a 

3 particular computer 

4 When, and il^ the customer submits the transaction form to the merchant, the 

5 transaction ID string is communicated to the merchant, along with other customer 

6 information such as name, address, wedit card number and the like plus transaction 

7 informatioa The complete transaction record is stored on the merchant's system and is 

8 associated with a spedfic machme identity profile within the archive service by way of the 

9 transaction ID string. Thereafter, the stored machine identity profiles and transaction 

1 0 records of large numbers of transactions can be analyzed by various fraud detection 

1 1 techniques to detect patterns of fraud and fi^ud attempts and, preferably, identify and 

1 2 locate the sources of such activity. 

13 The machine data profiles stored in the archive service need not be combined with 

14 the customer identification information for non-suspicious transactions, to thereby 

1 5 preserve the privacy of non-suspicious customers within the machine data archive. 

1 6 However, the processes of the present invention do not require that the customer 

1 7 identification information be kept sepamted from any associated machine data profiles, and 

1 8 there may be reasons to combme the associated records. 
19 

20 
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1 Brief Description of the Drawing s 

2 Fig. 1 is a simplified block diagram illustrating a plurality of customo- and 

3 merchant computers interfecedto the internet along with a machine data archiving service 

4 computer for practicing tiie machine data collection process of the present invention. 

5 Rg. 2 is a sunplified block diagram iUustrating connection of a customer computer 

6 to the internet, with optional componoits shown m phantom lines. 

7 Fig. 3 is a flow diagram illustrating prindpal steps of tiie machuie data collection 

8 and archiving process according to the present invention. 

9 Fig. 4 is a flow diagram iUustrating more detailed steps of the machine data 

1 0 collection and archhong process according to thie present invention. 

1 1 Fig. 5 is a flow diagram iUustrating a stiU fiirtiier detaUed steps in tiie machuie data 

1 2 coUection and archiving process of tiie present hxventioa 

1 3. Various objects and advantages of tiiis invention wUl become apparent fi'ora tiie 

1 4 foUowing description taken in relation to tiie accompan^g drawings wherein are set 

1 5 fortii, by way of ilhistration and example, certain embodiments of tiiis mvention. 

16 The drawings constitute a part of this spedfication, inchide exemplary 

17 embodiments of tiie present invention, and illustrate various objects and features tiiereof 
18 

19 
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1 Detailed Description of thelhventmn 

2 As required, detailed embodiments of the present invention are disclosed herdn; 

3 however, it is to be understood that the disclosed embodiments are merely ©cemplaiy of 

4 the invention, which may be embodied in various forms. Therefore, specific structural and 

5 fiinctional details disdosedherdn are not to be intopreted as Imutmg, but merely as a 

6 basis for the claims and as a representative basis for teaching one skilled in the art to 

7 variously ^ploy the present invention in virtually aay appropriate detailed stnicturfe. 

8 Referring to the drawings in more detdl: 

9 The reference num^ 1 (Kg. 3) g^ierally designates 

10 a process for online collection of machine identifying or profiling data of computers 

1 1 invoh^ed in commercial transactions and for archivii^ such data to fedUtate analy^s for 

12 ficaud detection purposes. The process collects machuie identifying or profiling data of 

1 3 computers mvolved in commercial transactions and archives such data in a third-party 

14 machine data archive service m association with a transaction identification string or ID 

15 vMch is also writtai into a transaction form of a merchant with whom the customer is 

16 conducting a transaction. 

17 Fig. 1 illustrates a phirality of host entities or merchants with corresponding 

1 8 merchant computers 2, on which are operated merchant web sites 3 which are accessible 

19 over a global computer networic, such as the internet 4, by a phitality of customer 

2 0 computers 5. The merchant computers 2 execute various programs whjph enable the sale 

21 ofproducts or services by way ofthe internet 4. The merchant web sites 3 typically make 

12 
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1 use of form type web pages with which the customers 5 interact by filling in various data 

2 fidds, for example, name, address, shipping address, telephone number, crecKt card type 

3 and numb^ and expiration date, and description and quantities of products to be ordered. 

4 The merchant transaction forms are usually written in hypertext mariaip language 

5 (HTML) and may inchide requests for code written in other languages, such as Java and 

6 the like. When a customer 5 accesses a merchants transaction form, a transaction form 

7 file is communicated to the customer's computer with various data fields displayed as fill- 

8 in boxes or the like. The customer fills in the appropriate fields and selects a submit 

9 "button" which activates a routine to trjinsfer the collected information back to the 

1 0 merchant web site 3 for processing. The returned "form" is a data record 6 which is 

1 1 stored in a merchant transaction database 7 for retrieval and processing in due course to 

12 cause the ordered items to be gathered, packaged and prepared for shipment, along with 

1 3 financial processing to debit the customer's credit account. The financial processing may 

1 4 mclude a validity check of the credit account and an autiiorization check for tiie amount of 

1 5 purchase with the credit card issuer. Additionally, inventory management processes are 

1 6 executed based on the items withdrawn fi-om stock for shipment. 

17 In a three party embodiment of the present invention, the process 1 makes use of * 

18 an entity referred to herdn as a machine data archiving service, MDAS or archive service, 

1 9 v^ch operates an archive service computer system 1 5, including an ardiive service web 
2 0 site 16. The archive service system 15 maintains a machme data archive service database 
21 or archive 17 in which the machine data collection profiles 18 fi^om customer computers 5 

13 
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1 of the merchants 2 are stored. The archive service web site 16 is interfeced to the internet 

2 - 4. The archive service 15 is preferably independent of the merchants and may be operated 

3 by a merdiants' association, a financial institution or association thereof or may be an 

4 independ^t contractor. AltOTiatively, it is conceivable that a merchant with a high 

5 volume of online sales could opmte its own in-house machine data profile collection and 

6 arcluving service 15, for fraud detection or possibly for marketing purposes. 

7 Referring to Fig. 2, a customer conqputer system 5 includes a customer computer 

8 20 interfaced to the irtemet 4 by way of a primary gateway 22, as of an internet service 

9 provider (ISP). The computer 20 might be one ofmany on a local area network or LAN 

10 24 whidi mcludes a router or switch which routes data fi"om the internet 4 to the 

1 1 computes on the network. The computer 20 may communicate tiirough tiie mtemet 4 by 

12 way of a HTTP (hypertext transfer protocol) proxy 26, whidi disguises tiie internet 

1 3 protocol (IP) address of the actual gateway 22. The computer 20 accesses web sites on 

14 the internet 4 usmg a customer web browser 28 which processes HIML language and 

1 5 various other standard web oriented languages to di^lay or otiierwise render the content 

1 6 of web pages and interact therewith. The browser 28 is normally enabled to accept 

1 7 "cookies'' 30 which are stored m a cookie ffle. Cookies 30 are data strings which are 

1 8 issued by web sites and give an indication of a previous visft to a particular web site and 

1 9 may mdicate a particular configuration or set of preferences of the customer's setup of tiie 
2 0 computer 20. Typically, tiie customer computer 20 has a time of day dodc/calendar 32. 
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1 The customer computer 20 may have a fixed IP address, depending on the manner 

2 in which it is interfeced,to the internet More commonly, the customer computer 20 will 

3 have a temporary or dynamically assigned IP address which is determined by the primary 

4 router 22. The primary routo- 22 has an IP address, as do a router of a LAN 24 or an 

5 HTTP proiqr 26 if either is present in the customo's conqmtor system 5. 

6 Fig. 3 illustrates the prindpal actions or steps of a general or basic process 34 of 

7 the process 1 for collecting machine identifying data firom customer computers 5. Atstq) 

8 35, at least one machine identifying profile parameta- is captured upoff access of a 

9 customer computer 5 or other onBne access device with a host or merchant web ate 3. A 

1 0 unique transaction identifier or TA/DD is generated at 36 and associated at 37 with the 

1 1 captured profile parameter. The transaction ID is also associated at step 38 with a 
transaction record generated as a result of tiie mteraction or transaction conducted 

13 between the customer computer 5 and a merchant web 'site 3. Although not specifically 

1 4 shown in Rg. 3, the process 34 may capture machine profile data that is passed ft^om the 

1 5 customer computer 5 to the merchant computer 3 as an inherent step of the customer 

1 6 computer 5 accessing the merchant computer 3. Alternatively, the process 34 may pass 

1 7 routines to the customer computer 5 to cause it to "self-identify" itself by querying certain 

1 8 configuration parameters and passing such information to a machine profile stored either 

1 9 withm tiie merchant's systan 2 or in a third party archive 17. The process 34, tiius, 

2 0 encompasses a two-party embodiment or a tijree party embodiment of tiie machine data 

2 1 collection mid archiving process 1 of tiie present invention. 
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1 Referring particularly to Fig. 4, a more particular three party embodiment of the 

2 machine data coUection and archiving process 1 be^s at step 40 with the coding of a 

3 machine data collection (MDC) script i^equest into the web page code for a transaction 

4 form of a merchant web site 3. When a customer 5 accesses the merchant transaction 

5 form at step 42, the customer browser 28 processes the transaction page code, inchiding 

6 the MDC script request, wWch causes the MDC script request to be commuiucated to the 

7 archive service web site 16 at step 44. The script request arrives at the archive service 15 

8 with a set of customer machine parameters which principally prb^dde a return path for the 

9 MDC script from the archive service 15 to the customer 5. The customer machine 

1 0 parameter set preferably includes "user agent" information, which is the version of the 

1 1 customer browser 2», 

12 At step 46, the archive service 15 generates a unique transaction ID string and 

1 3 associates it with the customer machine parameter set in the MDAS archive 17. At step 

14 48, the archive s^ce returns the MDC script, with the transaction ID embedded within 

1 5 it, to the customer browser 28. At step 50, the customer browser 28 processes the MDC 

1 6 script which, at a nummunj, writes the transaction ID string mto the merchant's transaction 

1 7 form. Assummg that the customer 5 completes the transaction and submits the transaction 

1 8 form to the merchant 2 at step 52, the transaction ID string is stored with the transaction 

1 9 data record 6 in the merchant transaction database 7. The transaction ID, thus, indirectly 
2 0 associates the machine data parameter set 1 8 stored in the MDAS archive 1 7 at step 54 

2 1 with the customer identity infonmation stored witii the transaction data record 6 in the 

16 
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1 merchant's transaction database 7. Thereafter, qualified parties may access the MDAS 

2 archive 17 for information related to a transaction ID. 

3 The MDAS archive 17 need not contain any information which specifically 

4 identifies a particular customer, only the machine parameter profiles 18 with assodated 

5 transaction ID strings. The MDAS ardiive records 18 can be analyzed in conjunction with 

6 the merchant transaction records for patterns of fraud or for other purposes. The great 

7 majority of MDAS archive records can be purged from the archive 17 after a selected 
8- period of time. Any records which are assodated with any transaction irregularities or 
9 suspicions of actual fraud may be retained longer. 

10 Rg. 5 illustrates the principal steps of a preferred embodiment 60 of the machine 

1 1 data collection and archiving process 1 of the present invraition. The process 60 begnis 

12 with the addition at 62 ofa machine data collection (MDC) script to the transaction (^^ 

1 3 form page code of a merchant web site 3. The fransaction form page code is processed at 

14 64 by a customer browso- 28 when the xderchant web page is accessed to Aereby request 

15 the MDC script at 66 from the Machine data archive service (MDAS) web site 16. When 

16 the browser 28 accesses the MDAS wd) ate 16, requesting the MDC script, the MDAS 

17 web site diecks for the presence of an MDAS cookie at step 68. If no MDAS cookie is 

1 8 detected, an MDAS cookie is generated at 70 and a unique^ansaction identification 

1 9 (TA/ID) string is generated at 72. The MDC script, transaction ID, and cookie, if not 
2 0 previously set, are returned at 74 to the customer browser 28, the transaction ID bemg 
2 1 embedded within the MDC soript 
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1 When the MDC script is received by the browser 28, it is executed at 76. The 

2 coolde is stored in the cookie file 30, or possibly in the memory of the customer computer 

3 20, Execution ofa preferred MDC script causes several actions to be performed. The 

4 MDC script writes the transaction ID into the transaction form at step 78. The script can 

5 do this by dther setting an existing variable of an appropriate name to the transaction ID 

6 string or by writing an appropriate variable into the transaction fonn page and setting its 

7 value to the transaction ID string. AdditionaUy, tiie preferred MDC script generates a 

8 "fingerprint' of the customer computer 20 at step 80 and attempts to perform a proxy 

9 piercing operation at step 82. 

10 In generating the machine fingerprint at 80, the MDC script queries the browser 28 

11 for a number of attributes and settings and concatenates the results into an attribute string 

12 at 84. The MDC script then performs a hashing algorithm on the attribute string at 80 to 

13 generate a fingerprint string which has a high degree of uniqueness. Hashing fimctions are 

1 4 irreversible encryption processes in which the result is dependent on the ori^al content of 

1 5 the data on which the hashing algorithm is operated. Hashing fimctions are commonly 

1 6 used for data integrity checking. As previousfy stated, a common checksum is the result 

17 ofa type of hashing fijnction. The particular hashing fiinction employed preferably 
1 8 . maximizes the uniqueness of the resulting fingerprint. 

19 At step 86, the customer computer clock 32 is queried for a current time value. At 

2 0 step 88, the fingerprint, the transaction ID, and tiie time value are communicated to the 

18 
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1 MDAS web site 16 along with an HTTP header with cookie and "apparent IP address, all 

2 of which are stored as « machine data profile 1.8 within the MDAS arduve 17. 

3 At step 90, the MDC script adds a projqr piercer request to the transaction form 

4 which, when executed by the browser 28 at step 92, sends a request for a proxy piercer 

5 applet or code to the MDAS web site 16. When the proxy piercer applet/code is executed 

6 by the browser 28 at 94, a time value from the clodc 32 is again queried at 96 and any 

7 existing local area network (LAN) address is queried at 98. At step 100, the proxy piercer 

8 applet/code sends the tune value,^ the LAN address (if any), and the transaction ID to the 

9 MDAS web ^te 16 by a protocol wMchbypasses any existmg HTTP proxy 26. The 

1 0 protocol used is one which is at a lower level than HTTP, such as UDP (user datagram 

1 1 protocol) or, preferably, TCP/IP (transmission control protocoWntemet protocol). 

1 2 Bypassing.the HTTP proxy 26 causes the data sent in step 100 to arrive at the 

1 3 MDAS web site 16 with the IP address of the primary gateway 22, which may be different 

1 4 from any apparent IP address previously recorded if an HTTP proxy 26 intervenes. If the 

1 5 proxy piercer procedure 82 is successfal, the primary gateway IP address is stored at step 

1 6 102 within the machine data profile 18 identified by the transaction ID. It should be noted 

17 that some types of proxies, such^ some types of firewalls, may block all non-HTTP 

1 8 protocol packets, so that the proxy piercer procedure 82 mijght not be successfiil m all 

19 cases. 
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If the customer completes the transaction with the merchant web site 3, the 
transaction form is submitted at step 104, which causes the transaction record 6, including 
the transaction ID, to be stored at step 106 in the merchant database 7 for processing. 

Following are examples of code for an MDC script, as from st^s 40 or 62. 
Assunung the madiine data ardiiving service or MDAS wdj site 16 has the fictional TIRL 
(uniform resource locator) example-url.net and a spedfic machant has a m^ant 
identifier MMM, a line of HTML code is added at step 40 to tiie transaction fonn of 
merchant MMM between the <fontt> and </form> HTML tags wMch has the fonn: 

<script sro=ht^s://www.example-url.net/s/?MMM></script> 

When the customs browsw 28 processes the transaction form at step 42, it 
requests a script file fi-om tiie source URL: httDs://www.examole-uri net/s/?MMM 

At step 44, the customer web browser 28 requests the MDC script by way of the 
HTTP protocol. The HiTF request includes the merchant ID MMM, the user agent 
(browser version), the IP address of the customer's HTTP proxy, and any HTTP cookies 
previously sent to the customer by wwnv.example-uri.net. Upon receiving this 
information, the archive sendee 16 records tiiis infijnnation in a macWne data record 
which also includes the transaction ID. 

Upon receiving the file request, the archive sendee 16 generates a unique 
transaction ID (represented below as ZZZ) at stq> 46 to be associated witii tiie transaction 
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1 and the machine parameter set. An exemplary transaction ID is a string of 24 letters and 

2 digits. The first dghtdi^ts form a time-stamp.which is a hexadecimal representation of 

3 the seconds elapsed since midnight January 1, 1970 UTC (coordinated univM-sal time). 

4 In the pr^emd embodiment of the process 1, the MDC script is written In an 

5 ECMAScaipt compliant language, such as JavaScript, JScript, or VBScript. A JavaSaipt 

6 version of the MDC script is as follows (linebreaks and indentations added for clarity): 
7 

8 document. write("<input name=transactionid 1ype=hidden value=ZZZ>; 
9 

10 d=newDateO; 
11 

1 2 t=3600*d.geiHoursO+60*d.getMnutesO+d.getSeGondsO; 

13 - ^ ■ ' 

14 documentwrite("<mghdg}it=lwidth=l sro=*t^s://www.e«impr©. 

15 url.net/t/?i=^;ZZ&t="+t+">''); 
16 

1 7 document.write("<applet height=l width=l 

18 codd}ase=https://www.exanq>Ie-urlnet/ 

19 cbde=a/?ZZZ> 

2 0 <param name4 value=ZZZ></applet>"); 
21 
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1 The exemplary MDC script includes the unique transaction ID value in several 

2 places. When the script executes on the customer computer 20, it writes HTML code into 

3 the merchant's order fomt Specifically: 

4 1). The script adds a hidden variable called "transactionid" to the merchant's 

5 transaction form and assigns it the value of the transaction ID (777 ) when the 

6 transaction form is submitted, the merchant receives the transaction ID and can assodate 

7 it with the transaction data record. 

8 2) The script computes the seconds elapsed since midnight on the clock 32 

9 and writes a request for a 1 pfacel by 1 pixel unage. Included in the request is the 

1 0 transaction ID and the time value. When the request executes, this data is sent back to the 

1 1 archive service 16 and recorded with the transaction ID in the MDAS archive 17. 

^2 3) The script adds a request for a program located at the archive service web 

1 3 site 16 which, in this example, is a Java applet the applet downloads to the customer 

1 4 computer 20 finom the archive service 16 and executes, appearing as a I pixel by 1 pixel 

1 5 image on the transaction form. The transaction ID is passed to the program as a 

1 6 parameter spedfied in the script. The program performs three tasks: 

1 ^ a) it calculates TTT, the seconds elapsed since midnight on the system clock 

18 32; 

^ ^ b) it calculates AAA, the address of the customer 20 on its own local area 

20 network 24; and 

22 
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c) it sends this data back to the archive service 16 via TCP/IP, by requesting 

thefoUowihgURL: 

http://www. exampl6-uri.net/d/?i=ZZZ&t=TTT&a=AAA 

The archive service 16 receives the message which includes the parameters TTT, 
AAA,andZZZ. The message also includes the IP address of the sender. This address is 
the customer's actual IP address, which in some cases is diflFerent from the HTTP prosy IP 
address. The archive service 16 records this information in the MDAS archive 17 and 
associates it with the transaction ID ZZZ. 

The machine data collection and archiving process 1 of the present invention has 
been described with a particular application in fraud detection. However, it is foreseen 
that the techniques of the present invention have a wider application, as for marketing or 
computer support purposes, or othca- functions. While the process 1 has been described 
with reference to the internet 4 or world wide web, it is also concdvable that the process 1 
could be employed on computer networks of less than gjobal e3q)anse, such as a large 
intranet, a national or regional network, or the like. 

Therefore, it is to be understood that while certam forms of the present invention 
have been illustrated and described hereui, the present invention is not mtended to be 
limited to the spedfic forms, arrangement of parts, sequenoe of steps, or particular 
applications described and shown. 
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CLAIMS 

What is daimed and desired to secure by Letters Patait is: 
A process for collecting machine identifying information associated with a distal 
onUne access device used for substantiaUy anonymously accesaqg a host compute 
system over a digital network; said host computer system generating an interaction 
record of an access therewith by said access device, and said process comprising 
the steps of: 

(a) capturing a machine identifying profile parameter upon s^d access device 
accessing said host computer systoii; 

(b) generating a unique mteraction identification string upon said access device 
accessuig said host computer syst^ 

(c) associating said interaction identification string witii said profile parameter, 

and " " 

id) assodating said interaction identification string with said interaction record 
generated upon said access device accesang said host computer system. 

A process as set fijrth m Chum 1 wherein said capturing step includes the step of: 
(a) capturing a digital address of said access de^ce on said digital network. 

A process as set forth m Claim 1 wherem said capturing step mdudes tiie step of; 
(a) capturing a configuration setting ofsaid access device. 

24 
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4. A process as set forth in Claim 1 and including the steps of: 

(a) conununicating a self-identification routine to said access device upon said 
access device acces^g said host computer system; 

(b) said access device executing said self-identification routine; 

(c) said self-idmtification routine, queiying a configuration setting of said 
access device to. derive said profile parametei^ and 

(d) said self-identification routine communicating said profile parameter to a 
remote location for association with said interaction identification string. 

5. A process as set forth ui Claim 1 and includmg the steps of: 

(a) said host system operating a host web site including an interaction page 
generated by interaction p.age code processed by said access device upon: 
accessing said host web site; and- 

(b) coding, within said interaction page code, a sdf-identification routine 
which causes said access device to communicate said profile parameter 
when said access device processes said mteraction page code. 

5. A process as set forth in Claim 3 and including the sftep jDf: 

(a) coding said self-identification routine in such a manner that said profile ^ 
parameter and said interaction identification string are communicated to a 

. 25 
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third party web site at which said profile parameter and said interaction 
id^itificsition string are stored. . 

A process for identifying a customer computer involved in an online transaction 
between a customer using a customer browser operating on said customer 
computer and a merchant operating a merchant web site, said method comprising 
the steps o£ 

(a) capturing a customer computer profile parameter upon said customer 
con^utor accesang said merchant wd> site; 

(b) generating a transaction identification string and assodating said string 
with said parameter; 

. (c) storing said paramet^md said string in a machine data aictdve; 

(d) - upon said customer completing a transaction through said merchant wd> 
site, storing said transaction identification string with a transaction record 
formed during said transaction to thereby assodate said parameter with 
said transaction record through said string. 

A process as set forth in Clahn 7 wherein said captiiring step inchides the step of 
(a) capturing an P address of sdd customer compute-. 
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9. A process as set forth in Claim 7 wherein said capturing step includes the step of: 
(a) capturing a configuration setting of said customer computer. 

10. A process as set forth in Claim 7 and including the step of: 

(a) conununicating said proffle parameter and said transaction identification 
string to a third party web site for storage. 

11. A process as set forth in Claim 7 and including the step of: 

(a) causing said customer computer to communicate said profile parameter and 
said transaction identification string to a third party web site for storage. 

12. A process as set forth in Claim 7 and including the steps of: 

(a) communicating a self-identification routine to said customer computer 
upon said customer compute accessing said merchant web site; 

(b) said customer computer executing said self-identification routine; 

(c) said self-identification routine querying a configuration setting of said 
customer computer to derive said profile parameter; and 

(d) said self-identification routine communicatiiig said profile parameter to a 
remote location for association with said interaction identification string. 
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13. A process as set forth in Claim 12 and including the step of: 

(a) coding s£ud self-identification routine in such a manner that said profile 
parameter and said interaction identification string are communicated to a 
third party web site at which said profile paramet^ and said interaction 
identification string are stored. 

14. A process as set forth in Claim 12 wherein said querying step includes the steps of: 

(a) querying said customer browser for a plurality of configuration settings; 

(b) forming an attribute string firom said plurality of configuration settings; and 

(c) processing said attribute string to form said profile parameter of said 
customer computer. 

15. A process as set forth in Claim 12 wherein said customer computer potentially 
accesses said merchant web site by way of a proxy, and said communicating step 
includes the steps of: 

(a) communicating said profile parameter and said transaction identification 
string to said remote web site using a protocol which bypasses said proxy. 

16. A process for identifying a customer computer involved in an online transaction 
through a merchant web site between a customer using a customer browser 
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operating on said customer computer and a merchant who operates said web site, 
said method comprising the steps of: . 

(a) coding a script request within a transaction form of said merchant web site; 

(b) processing said script request by said customer browser upon accessmg 
said merchant web site to thereby communicate to an archiver web site of a 
machine data archiving service an electronic request for a machine data 
collection script; 

(c) said archiver web site returning said script to said customer browser along 
with a unique transaction identification string; 

(d) said customer browser processing said script to thereby cause said script to 
query said customer computer for a profile parameter of said customer 
computer; 

(e) said script causing said customer browser to communicate said profile 
parameter and said tnmsaction identification string to said archiver web 
site; 

(f) said archiver web site storing said profile parameter and said transaction 
identification string in a machine data profile; 

(g) said script causing said customer browser tb write said transaction 
identification string into said transaction form; and 

(h) upon said customer adding customer identification information to said 
transaction form and electronically submittmg said transaction form to said 
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merchant web site to thereby comprise a transaction record, said 
transaction identification string associating said transaction record with said 
machine data profile. 



17. A process as set forth in Claim 16 and including the steps of: 

(a) said script causing said computer browser to communicate said profile 
parameter and said transaction identification string along with a 
conventional hypertext transfer protocol (HTTP) header; and 

(b) said archiver service additionally storing said HTTP header in association 
with said machine data profile. 

18. A process as set forth in Claim 1 6 and including the step of: 

(a) said script querying said customer browser for a configuration setting 
thereof 



19. A process as set forth in Claim 16 and including the steps of: 

(a) said script querying said customer browser for a plurality of configuration 
settings; 

(b) said script forming an attribute string firom ssud plurality of configuration 
settings; and 



30 



wo 01/97134 



PCTAJSOl/18076 



(c) said script processing sdd attribute string to form said profile parameter of 
said customer computer.- 

20. A process as set forth in Claim 19 wherdn said script processing step includes the 
stepo£ 

(a) said script performing a hashing function on said attribute string to form 
said profile parameter. 

21 . A process as set forth in Claun 16 wherein said customer computer potentially 
accesses said merchant web site by way of a proxy, and including the step of: 
(a) said script communicating said profile parameter and said transaction 

identification string to smd ardiiver service web site using a . protocol which 
bypasses said proxy. 

22. A process as set forth in Clahn 16 and including the step of: 

(a) said script communicating said profile parameter to said archiver service 
web site using a protocol other than HTTP. I 

23 . A process as set forth in Claim 16 x^eriwn said customer computer includes a 
digital clock, and including the steps of: 
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(a) said script causing said customer browser to query said clock for a time 
value; and 

(b) said script causing said customer browser to send said time value to said 
archiver s^ce web site along with said profile parameter 

24. A process for identifying a customer computer involved in an online transaction 
through a merchant web site between a customer using a customer browser 
operating on said customer computer and a merchant who operates said web site, 
said method comprising the steps of: 

(a) coding a script request within a transabtion form of said merchant web site; 

(b) processing said script request by said customer browser upon accessing 
said merchant web site to thereby communicate to.an archiver web site of a 
machine data archiving service an electronic request for a machine data 
collection script; 

(c) said archiver web site returmng said script to said customer browser along 
with a unique transaction identification string; 

(d) said customer browser processing said script to thereby cause said script 
to: 

(1) query said customer browser for a plurality of configuration 
settings; 

(2) forrn an attribute string fi-om said phirality of configuration settings; 
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(3) perfonn a hashing function on said attribute string to fonn said 
profile.parameter; and 

(4) query an internal digital clock of said customer computer for a 
current time value; 

(e) said script causing said customer browser to communicate said profile 
parameter, said time value, and said transaction identification string to said 
archiver web site along with a conventional HTTP header, 

(f) said archiver web site storing said profile parameter, said time value, and 
said transaction identification string in a machine data profile; 

(g) said script causing said customer browser to write said transaction 
identification string mto said transaction form; and 

(li) upon said customer adding customer identification information to said 

transaction form and electronically submitting said transaction fonn to said 
merchant wrf> sdte to therd>y comprise a transaction record, said 
transaction identification string assodating said fansaction record with said 
machine data profile. 

A process as set forth in Claim 24 vterein said customw cbnqwta- potentialfy 
accesses said merchant web site by way of a proxy, and including the steps of 
(a) said script querying said customer computer for a second profile parameter; 
and 
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(b) said script communicating said second profile paramet^ and said 

transaction identification^ string to said archiver service web site using a 
protocol which bypasses said proxy. 

A process as set forth in Claim 25 and inchiding the step of: 
(a) said script communicating said second profile parameter to sdd archiver 
service web site using a protocol other than HTTP. 
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